In the field of project scheduling, often “tasks” (e.g., activities to be performed or completed) are assigned to “resources” (people, machines etc.). A task has a given amount of work associated with it (effort required to complete the task), usually specified in hours. The work value is a scalar value, which by itself is not relative to any particular time. For example, assume that a task entitled “Pour foundations for house” entails 12 hours of work (man hours of effort). In order to schedule this task, a starting date must be defined and the work assigned to various resources. For purposes of illustration, let us assume an arbitrary start date for this task of 8:00 AM on Monday Aug. 1, 2004.
In a conventional scheduling software product such as Microsoft® Office Project, a “calendar” defines when work can occur. In Project, each resource has an effective calendar associated with it. For example, assume a resource named “Bob” has a calendar that indicates he works 8 hours a day, 5 days a week (Monday-Friday). This exemplary calendar would include exact shift timings, thus for each weekday, assume there is a shift 8:00 am-12:00 pm and 1:00 pm-5:00 pm, which yield 8 available working hours per day. Assuming that Bob is the only resource assigned to the task “Pour foundations for house”, the scheduling engine of Microsoft® Project is now able to determine when the task work is actually done. The engine begins at the task start date, and then plots the required task work (12 hours in this case) into the available shifts indicated by Bob's calendar. Since the task is starting on Aug. 1, 2004, a Monday, the scheduling engine will use the calendar functionality to determine what working time if any Bob has for Monday August 1. It will find that there are two shifts available on Monday, with 4 hours each. It will then plot 8 hours of the task work into the two shifts, leaving 4 hours remaining. Since work is still remaining, the engine will continue to scan Bob's calendar in the forward direction, looking for more available working time. The next day, August 2 is a Tuesday. Bob's calendar again indicates two shifts. Since only 4 hours remain, the calendar functionality will plot the remaining 4 hours into the first shift. Since the first shift ends at 12:00 PM, the engine is now able to determine that the task will actually be finished on Aug. 2, 2004, at 12:00 PM. This example is highly simplified. However, it illustrates how calendars are used by a scheduling software engine to turn generic task work requirements into absolute dates. The calendar functionality is at the core of a work-scheduling algorithm. The calendaring functionality ultimately determines when work can actually happen—thus it is critical that the routines that manage and interpret calendar data be as highly optimized as possible.
For the end user (project manager) of a product like Project, defining a calendar on a day-by-day basis can be extremely time consuming for a project that may have work spanning several hundred days. Thus, the concept of a “standard week” is used in order to simplify the process. This allows the user to specify the default working time for each weekday (Sunday-Saturday), to serve as the default definition for a given day. Of course, sometimes the user will wish to override a particular day (e.g. Saturdays may generally be non-working on a given calendar, but due to time constraints, the user may wish to indicate that a specific Saturday is in fact a working day). The deviations from the standard week are called “calendar exceptions”.
There are algorithmic complexity implications associated with defining calendars via a “standard week” and then overriding select days with “exceptions”. For large projects, there may be several hundred exceptions to track on a per calendar basis. Without care in the design of software architecture supporting this model, the scheduling software could be slowed to the extent that the product is non-viable.
In conventional project scheduling applications, the user is allowed to specify calendar “exceptions” for specific days. For example, a user can select a particular span of days (say Aug. 25, 2004 to Aug. 30, 2004) and indicate that for each of these days, a half-time shift was present (regardless of what the standard week definitions for those days might indicate). In real life usage, such calendar exceptions usually follow a pattern, so the fact that a conventional program forces the user to specify each span individually is often an inconvenience. For example, it may be necessary to mark every December 25 as a non-working day. If the project spans multiple years, the user would have to modify December 25 for each year individually.
Defining a calendar for each resource can be very tedious, especially when many of the resources have similar calendar structures. Further, typically there is only one definition of the “standard week” for each calendar. In other words, there is only one definition of Sunday, Monday, Tuesday etc. for each calendar. Any deviation from these weekday definitions requires the use of calendar exceptions. This limitation is particularly annoying in the scenario where the standard working week for a particular resource changes during the execution of a long term project.
For example, let us stipulate that a project starts August 1. Bob works on the project, and initially his work week is defined to be a standard 5-day work week, Monday-Friday, with two 4-hour shifts per day. Then, starting the week of August 15, Bob goes to half time on Tuesdays. The conventional scheduling program user must be very careful when effecting this change, because if he/she changes Bob's Tuesday definition, any changes or rescheduling of tasks with work scheduled prior to August 15 involving Bob on Tuesday may become inadvertently incorrect. The reason is that in a conventional scheduling program such as Microsoft® Office Project, there is only one definition for Tuesday for a given calendar. Any change to it immediately extends to all prior and future dates. Prior to August 15, Bob is in fact working full time on Tuesdays, but there is no way to indicate that except via specific calendar exceptions for each Tuesday prior to August 15 in the calendar—which the user might not initially think to add. It is with respect to these and other considerations that the present invention has been made.